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(54) Events as activities In process models of workflow management systems 



(57) The present invention relates to the area of 
workflow management systems (WFMS). WFMS exe- 
cute a multitude of process models consisting of a net- 
work of potentially distributed activities. The current 
invention is dedicated to the implementation of events 
within WFMS. The current invention teaches to imple- 
ment events like any otter process activity. 
Thus events are implemented as event-activities, a spe- 
cial type of an activity within saJd WFMS. Such an 
event-activity can manage an went occurring internal or 
external to the WFMS. 

This approach allows to make ail features available to 
common activities also accessible to event activities; 
examples are: input*eontainer and/or output-container, 
control-connectors, data-connectors, notification-mech- 
anisms, preeficates associated to control connectors 
forming transition conditions and many more. A control 
connector leaving an event activity, which optionally 
may be associated with a logical predicate as outgoing 
transition condition, allows the WFMS to automatically 
activate a target activity if said event activity terminated 
after the event has been signaled to said event activity 
and if the outgoing transition condition evaluates to true- 
Similar an incoming control connector, which optionally 
may be associated with a logical predicate as incoming 
transition condition, allows a WFMS to automatically 
activate an event activity if the process activity being the 
source of said incoming control connector terminated 
and ff said incomin^-transitton-concrrtion evaluates to 
true. 

This invention also teaches to extend the navigator of a 
WFMS by an event management system which inter- 



operates with the navigator to deliver above mentioned 
functionality. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in a awaited event table and further 
administering signaled events in a posted event table. 
The event management system further encompasses 
the component of an event manager maintaining infor- 
mation on events allowing to verify correctness of an 
event 
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Description 

1 Background of the Invention 

1.1 Field of the Invention 

The present Invention relates to the field of compu- 
ter systems acting as workflow management systems 
(WFMS). 

1.2 Description and Disadvantages of Prior Art 

A new area of technology with increasing impor- 
tance is the domain of Workfk>w-l/!anageinem<Sys< 
terns (WFMS). WFMS support the modelling and 
execution of business processes. Business processes 
control which piece of work of a network of pieces of 
work will be performed by whom and which resources 
are exploited for this work, i.e. a business process 
describes how an enterprise will achieve its business 
goals. The individual pieces of work might be distributed 
across a muftfoide of different computer systems con- 
nected by some type of network. 

The process of designtng, developing and manu- 
facturing a new product and the process of changing or 
adapting an existing product presents many challenges 
to product managers and engineers to bring the product 
to market for the least cost and within schedule while 
maintaining or even increasing product quality. Many 
companies are realizing that the conventional product 
design process is not satisfactory to meet these needs. 
They require early involvement of manufacturing engi- 
neering, cost engineering, logistic planning, procure- 
ment, manufacturing, service and support with the 
design effort Furthermore, they require planning and 
control of product data through design, release, and 
manufacturing. 

The correct and efficient execution of business 
processes within a company, e. g. development or pro- 
duction processes, Is of enormous importance for a 
company and has significant influence on company's 
overall success in the market place. Therefore, those 
processes have to be regarded similar as technology 
processes and have to be tested, optimized and moni- 
tored The management of such processes is usually 
performed and supported by a computer based process 
or workflow management system. 

In D. J. Spoon: "Project Management Environ- 
ment", IBM Technical Disclosure Bulletin, Vol. 32, No. 
9A, February 1990, pages 250 to 254, a process man- 
agement environment is described including an operat- 
ing environment, data elements, and application 
functions and processes. 

In R T. Marshate "IBM's RowMark, Object-Ori- 
ented Workflow for Mission-Critical Applications", Work- 
group Computing Report (USA), Vol. 17. No. 5, 1994, 
page 3 to 13, the object character of IBM RowMaik as 
a client/server product bust on a true object model that 



is targeted for mission-critical production process appli- 
cation development and deployment is described. 

In H. A. Inniss and J. H. Sheridan: "Workflow Man- 
agement Based on an Object-Oriented Paradigm", IBM 

s Technical Disclosure Bulletin, Vol. 37, No. 3, March 
1994, page 165, other aspects of object-oriented mod- 
elling on customization and changes are described 

In F. Leymann and D. Roller 'Business Process 
Management with FIowManV, Digest of papers, Cat 

10 No, 94CH3414-0, Spring COMPCON 94, 1994. pages 
230 to 234, the state-of-the-art computer process man- 
agement tool IBM FlowMark is described. The meta 
model of IBM FlowMark is presented as waII as the 
implementation of IBM FlowMark. The possibilities of 

is IBM FlowMark for modelling of business processes as 
well as their execution are discussed. The product IBM 
FlowMark is available for different computer platforms 
and documentation for IBM RowMaik is available in 
every IBM branch. 

so In F. Leymann: "A meta model to support the mod- 
elling and execution of processes", Proceedings of the 
11th European Meeting on Cybernetics and System 
Research EMCR92, Vienna, Austria. April 21 to 24, 
1992. World Scientific 1992, pages 287 to 294, a meta 

25 model tor controlling business processes is presented 
and discussed in detail 

The IBM RowMark far OS/2*, document number 
GH 19-8215-01, IBM Corporation. 1994. available In 
every IBM sales office, represents a typical modern, 

so sophisticated, and powerful workflow management sys- 
tem. It supports the modelling of business processes as 
a network of activities; refer for instance to "Modeling 
Workflow", document number SH 1 9-8241 , IBM Corpo- 
ration, 1996. This network of activities, the process 

35 model, is constructed as a directed, acyclic weighted, 
colored graph. The nodes of the graph represent the 
activities or workitems which are performed. The 
edges of the graph, the control connectors, describe 
the potential sequence of execution of the activities. 

40 Definition of the process graph Is via the IBM FlowMark 
Definition Language (FDL) or the bultfn graphical edi- 
tor. The runtime component of the workflow manager 
interprets the process graph and distrfcutes the execu- 
tion of activities to the right person at the right place, e, 

4$ q. by assigning tasks to a work list according to the 
respective person, wherein said work Est is stored as 
digital data within said workflow or process manage- 
ment computer system, 

in F. Leymann and W, Aftenhuber: "Managing busi- 

so ness processes as an information resource 11 , IBM Sys- 
tems Journal, Vol. 32(2), 1994, the mathematical theory 
undertying the IBM RowMark product is described. 

In D. Roller: "Ventilation von Workflows in IBM 
FlowMark", in J. Becker und 01 Vbssen (Hrsg.): 

5S ^esxhaeftsprozessmodelfierung und Workflows", 
International Thompson Publishing, 1995, the require- 
ment and possibility of the verification of workflows is 
described. Furthermore the feature of graphical anima- 
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tion for verification of the process logic is presented as 
it is implemented within the IBM FlowMark product. 

For implementing a computer based process man* 
agemerrt system, firstly the business processes have to 
be analyzed and, as the result of this analysis, a proc- s 
ess model has to be constructed as a network of activi- 
ties corresponding to the business process. In the IBM 
FlowMark product the process models are not trans- 
formed into an executable. At run time, an instance of 
the process is created from the process model, called a iq 
process instance. This process instance is then inter- 
preted dynamically by the IBM FlowMark product 

The concept of a/ante ac euch on the other hand is 
known in the state of the art Events for example play a 
role in database management systems. In database is 
management systems event/trigger mechanism have 
been developed for consistency checking in databases 
as described lor instance in A. M. tote, Triggermecha- 
nismen in Datenbanksysteman, Springer Vertag, BerGn 
1989. Also events play a central role in the notion of so 
active databases. In workflow systems, the semantics 
of an event is quite imprecise as applied by A. W. 
Scheer, Wirtschaftsinfbrmatlk. Springer Vertag, Berlin 
1 994 , where the event can be a termination condition of 
a previous activity or an external signal, such as the 25 
arrival of a -letter or in general an incident occurring 
Independent from an activity informing an activfty asyrv 
chroneously on some type of change. According to this 
prior art approach an event is restricted to a quite lim- 
ited spectrum of possible sources. The relationship so 
between the activity and the event may be such that the 
activity requires that the event is signaled to it otherwise 
the activity will not continue beyond a certain point. It is 
also possible that an event signaled to an activity will be 
perceived by that activity and depending on that percep- $s 
tion might modify the activity's ongoing processing. An 
event might result from anywhere within a computer 
system or even within networks of computer systems. 
Also the source of an event might be a hardware device, 
some software construct a human interacting with a 40 
running computer system and so forth. 

1 .3 Objective of the Invention 

The invention is based on the otyactive to tightly 4s 
integrate event mechanisms into wortf low management 
systems. 

2 Summary and Advantages of the Invention 

so 

The objective of the invention is solved by claim 1 . 
WFMS, encompassing one or more computers, execute 
a multitude of process models consisting of a network of 
potentially distributed activities. For each activity infor- 
mation is defined within the WFMS which available pro- ss 
grams or processes do execute that activity. The current 
invention teaches to realize an event as an event activity 
encompassed by said process model said event activity 



being implemented as a special type of activity of said 
WFMS and said event activity managing an event which 
may occur internal or external to the WFMS. 

The technique proposed by the current Invention 
achieves a new level of integration between WFMS and 
event technology. By exploiting and reusing the activity 
features very economic implementations for events are 
achieved. In addition conceptual gaps between the con- 
cepts of activities such as program or process and 
events are completely avoided. Moreover the approach 
allows to handle both, events occurring due to incidents 
within the WFMS as well as events having their source 
external to a WFMS. By conceptual!/ handling an event 
as any other activity (for instance as a process activity), 
this concept allows to treat realty any type of incident 
within a computer system as an event. The current 
approach thus supports the broadest possfcle spectrum 
of possfate events. By reusing to a certain extend the 
implementations of activities the overall system of a 
WFMS is not increased supporting compact and very 
responsive overall WFMS. 

Additional advantages of the invention are accom- 
plished by claim 2. 

According this teaching said went activities are imple- 
mented by inheriting features and capabilities of the 
class of activities or of a sub-cl ass thereof according to 
the principles of object-orientation. 

Such an approach allows for an elegant and very 
simple way of reusing capabilities already available 
within a system. 

Further additional advantages of the invention are 
accomplished by claim 3, - 

Claim 3 teaches to implement event activities by associ- 
ating with it an event generator being a program imple- 
menting said event According to the invention an event 
activity may have associated with it an input container 
and/or an output-container, the event activity may be the 
source and/or target of one or more control-conn ectors 
and the event activity may be the source and/or target of 
one or more data-connectors. Moreover it is taught by 
the current teaching, that the event activity may be 
associated with a notification mechanism allowing to 
freely define one or more actions to be performed by thB 
WFMS if the event activity is not completed within a 
freely defined time period. 

This approach to events supports a complete trans- 
parency whether an event is of internal or external 
nature. Nevertheless the teaching allows to implement 
the event generator as a special purpose program 
implementing or handling really any type of event Sep- 
arating tie general aspects of an event, like signaling a 
dedicated consumer that the event happened, from the 
event generator avoids that these functions have to be 
realized over and over again. Instead these general 
aspects are implemented only once within the WFMS 
and are handled by the WFMS automatically. Of course 
aS features which are available to normal activities are 
made available to event activities too thus easing the 
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implementation of events significantly. For instance 
input and output containers allow to provide an event 
generator with run-time information or to make results of 
an event available to consumers of an event. 

Further additional advantages of the invention are 5 
accomplished by claim 4. 

The invention suggest to introduce as one possible 
action which may be performed by the notification 
mechanism to automatically terminate the event if the 
event is not completed within a predefined time period. io 

Such an approach allows to simulate a successful 
termination of an event activity if required. 

Further additional advantages of tho invention are 
accomplished by claim 5 and 7. 
The current teaching allows that an event activity may is 
be the source of one or more, outgoing control connec- 
tors targeting at corresponding target activities. Such a 
process model win then mate sure that the target activ- 
ities wfll be Informed automatically by the WFMS on the 
event once the event is signaled to the waiting event 20 
activity an the event activity terminated. An outgoing 
control connector optionally may be associated with a 
logical predicate as outgoing transition condition mode- 
ling the feet that a target activity will be activated if said 
event activity terminated and said outgoing transition 2s 
condition evaluates to true. The current invention fur- 
thermore teaches that one or more incoming control 
connectors of the corresponding source activities may 
targeting at an event activity. Such a process model will 
then allow the WFMS to automatically start the event so 
activity once a source activity terminated its processing. 
An incoming control connector optionally may be asso- 
ciated with a logical predicate as incoming transition 
condition modefing the fact that the event activity w3I be 
started only by the WFMS if in addition said incoming as 
transition condition evaluates to true. 

By this approach already the process graph allows 
to define via the control connectors which other activi- 
ties are to be started after an event or which process 
activities automatically start an event activity. This tech- 46 
nique establishes a standard approach to inform poten- 
tial consumers on an event and to start an event activity 
and event generators. Thus the event activities, the 
event generators or the potential consumers are 
relieved from performing extra activities for that pur- 45 
pose. Moreover event generators and event activities 
with interest in a certain event (either in creating or in 
wailing on an event) become significant easier to imple- 
ment In addition above mentioned handling of the 
events is done automatically by the WFMS. The current w 
invention does not restrict these source and target activ- 
ities to a specific type Of WFMS activities. Therefore the 
source ancVor target activities might represent standard 
process activities, program activities or other types of 
activities but according to the current invention It would ss 
be also possible that one or both of them represent also 
event activities. In other words the current invention also 
supports chains or even complex graphs of event activ- 



ities. 

Further additional advantages of the invention are 
accomplished by claim 8. 

According claim 6 the WFMS is activating an event 
activity automatically when instantiating a process 
model if said event activity is not a target of a control 
connector. 

Thus no extra implementation is required to start a 
certain event generator. The WFMS takes care about 
these aspects automatically. 

Further additional advantages of the invention are 
accomplished by claim a 

Accorcfing to daim 8 the WFMS rogictorc said event 
activity as awaiting consumer of said event once said 
event activity is activated by the WFMS and wherein fur- 
ther said WFMS registers said event as posted event 
once the occurrence of said event is signaled by said 
event generator. 

Due to this teaching again the implementation of an 
event activity becomes much easier as the interest in a 
certain event is automatically detected by the WFMS by 
reading the process graph and the WFMS takes over 
responsibility to register an event activity's interest in 
that event Moreover the implementation of event gener- 
ators is also significantly simplified as an event signaled 
by an event generator is registered automatically by the 
WFMS as posted event 

Further additional advantages of the invention are 
accomplished by claim 9. 

The teaching suggests that a target activity is activated 
by said WFMS if as a first condition the event activity 
terminated and if as a second condition the outgoing 
transition condition evaluates to true independent at 
which point in time and in which sequence said first and 
said second condition are fulfilled. 

This behavior characteristic avoids that the sig- 
naled event is "consumed" if the transition condition is 
not fulfilled exactly at the point in time the event 
occurred. 

Further additional advantages of the invention are 
accomplished by claim 10. 

Claim 10 suggest to extend the WFMS navigator, per- 
forming navigation of operation trough the process 
graph of a process-model, by an event management 
system extending and inter-operating with said WFMS 
navigator. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in at least one awaited event table 
and further administering signaled events in at least one 
posted event table. An event generator is signaling the 
occurrence of said event to said event monitor. 

This teaching extends the navigator with additional 
features to administer on one side all events which have 
been signaled to and to handle on the other side all 
potential consumers of an event and to associate both 
sides. Neither event generators nor activities do have to 
take care of these aspects. 

Further additional advantages of the invention are 
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accomplished by claim 11. 

The teaching of claim 11 suggests an event manage- 
ment system encompassing the component of an event 
manager maintaining information on the events allowing 
to verify correctness of an event if said event is being 
signaled 

Such an access further increases the reliability of 
the overall system. 

Further adcfittonal advantages of the Invention are 
accomplished by claim 12. 

According to claim 1 1 the WFMS sends, H it detects that 
an event activity is awaifing for an event, an awaited 
event notification to said event monitor and if then said 
event monitor detects a matching posted event indica- 
tion in said posted event table said event monitor indi- 
cates said event together with event data to said WFMS. 
If otherwise no matching posted event notification is 
detected said event monitor stores an awaited event 
indication in said awaited event table. Also according to 
claim 12 said event generator indicates the occurrence 
of an event by a posted event indication to said event 
monitor which verifies said posted event indication by 
consulting said event manager and then stores said 
posted event indication in saJd posted event table and if 
then said event monitor detects a matching awaiting 
event indication in said awaiting event table rl indicates 
this together with event data to the WFMS. 

The approach of claim 1 2 improves responsiveness 
of the WFMS by at once checking whenever either a 
new event arrived or a new consumer is waiting for an 
event whether a matching event-consumer pair can be 
detected allowing the WFMS to inform frat consumer 
on the signaled event. 

Further adoptions) advantages of the invention are 
accomplished by claim 13. 

Claim 13 teaches that an event generator is informed, if 
an awaited event indication is stored in said awaited 
event table, on this awaited event indication. 

This technique informs an event generator auto- 
matically on consumers awaiting some kind of event 
Such an approach avoids that an event generator peri- 
odicaBy has to check for possible event consumers and 
thus avoids performance degradations. 

3 Brief Description of the Drawings 

Figure 1 is a diagram-reflecting multiple aspects of 

the embedding of events as a new type of 

activity within a WFMS 
Figure 2 is a visualization of the two fundamental 

embedding modes of events as event 

activities within a process model 
Figure 3 reflects the major components of the 

Event Management System 
Figure 4 depicts the structure of the "awaited event 

table* and the "posted event table" 
Figure 5 is a visualization of the FDL registration 

definitions required to modal an event 



Figure 6 is a visualization of the FDL definition of 
an event 

Figure 7 is a visualization of the FDL definition for 
exploiting the notification mechanism for 
5 an event 

Figure 8 is a simple sample process model reflect- 
ing the usage of event activities 

Figure 9 reflects the most important data struc- 
tures of the example of Figure B 
io Figure 10 is a visualization of an event modeled as 
an event activity witrwi the process model 
of the example of Figure 8 

4 Description of the Preferred Embodiment 

15 

The current invention is illustrated based on IBM's 
RowMark workflow management system. Of course 
any other WFMS could be used instead. Furthermore 
the current teaching applies also to any other type of 
20 system which offers WFMS functionalities not as a sep- 
arate WFMS but within some other type of system. 

4.1 Introduction 

25 The following is a short outline on the basic con- 
cepts of a workflow management system based on 
IBM's RowMark WFMS: 

Bom an enterprise point of view the management 
of business processes is becoming increasingly impor- 

30 tant business processes or process for short control 
which piece of work will be performed by whom and 
which resources are exploited for true work, Le. a busi- 
ness process describes how an enterprise will achieve 
its business goals. A WFMS may support both, the 

3s modeling of business processes and their execution. 

Modeling of a business process as a syntactical 
unit in a way that is directly supported by a software sys- 
tem is extremely desirable. Moreover, the software sys- 
tem can also work as an interpreter basically getting as 

4o input such a model: The model, called a process 
model or workflow model, can then be instantiated 
and the individual sequence of work steps depending 
on the context of the instant'alion of the model can be 
determined. Such a model of a business process can be 

4s perceived as a template for a class of similar processes 
performed within an enterprise; it is a schema describ- 
ing ail possible execution variants of a particular kind of 
business process. An instance of such a model and its 
interpretation represents an individual process, I.e. a 

so concrete, context dependent execution of a variant pre- 
scribed by the model A WFMSs faclISates the manage- 
ment of business processes. It provides a means to 
describe models of business processes (build time) and 
it drives business processes based on an associated 

ss model (run time). The meta model of IBM's WFMS 
RowMark, i.a the syntactical elements provided for 
da&crttng business process models, and the meaning 
and interpretation of these syntactical elements, is 
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described next. 

A process model is a complete representation of a 
process, comprising a process diagram end the settings 
that define the logic behind the components of the dia- 
gram. Using various services provided by RowMark 
these buildtime definitions the process models are then 
converted into process templates for use by RowMark 
at runtime. Important components of a RowMark proc- 
ess model are; 

m Processes 

■ Activities 

■ Blocks 

■ Control Rows 

■ Connectors 

■ Data Containers 

■ Data Structures 

■ Conditions 

■ Programs 

■ Staff 

Not all of these elements will be descnbed below. 

On this background a process, modeled by a proc- 
ess model within FfowMarK is a sequence of activities 
that must be completed to accomplish a task The proc- 
ess is the top-level element of a RowMark wortftow 
model. In a FtawMark process, it can be defined: 

• How work is to progress from one activity to the 
next 

■ Which persons are to perform activities and what 
programs they are to use 

• Whether any other processes, called subproc- 
esses, are nested in the process 

Of course multiple instances of a RowMark process can 
run in parallel. 

Activities are the fundamental elements of the 
meta model. An activity represents a business action 
that is from a certain perspective a semantical entity of 
its own. With the model of the business process H might 
have a fine-structure that is then represented in turn via 
a model, or the details of it are not of interest at all from 
a business process modeling point of view. Refinement 
of activities via process models allows for both, mode- 
ling business processes bottom-up and top-down. 
Activities being a step within a process represents a 
pace of work that the assigned person can complete by 
starting a program or another process, in a process 
model, the following information is associated with each 
activity: 

• What conditions must be met before the activity can 
start 

• Whether the activity must be started manually by a 
user or can start automatically 

• What condition indicates that the activity Is com- 
plete 



* Whether control can exit from the activity automati- 
cally or the activity must first be confirmed as com- 
plete by a user 

* How much time is allowed for completion of the 
5 activity 

* Who is responsible for completing the activity 

* Which program or process is used to complete the 
activity 

* What data is required as input to the activity and as 
10 output from H 

A RowMark process model consists of the fofl owing 

typas of activities: 

is Program activity: Has a program assigned to per- 
form it The program is invoked when the activity is 
started, tn a fulfy automated workflow, the program 
performs the activity without human intervention. 
Otherwise, the user must start the activity by select- 
so ing it from a runtime work list. Output from the pro- 
gram can be used in the exit condition for the 
program activity and tor the transition conditions to 
other activities. 

Process activity: Has a (sub-)process assigned to 
2$ perform it The process is invoked when the activity 
is started. A process activity represents a way to 
reuse a set of activities that are common to different 
processes. Output from the process, can be used in 
the exit condition for the process activity and for the 
30 transition conditions to other activities. 

The flow of control, i.e. the control flow through a 
running process determines the sequence in which 
activities are executed. The RowMark workflow man- 
as ager navigates a path through the process that is deter- 
mined by the evaluation to true of start conditions, exit 
conditions, and transition conditions. 

The results that are in general produced by the 
work represented by an activity is put into an output 
40 container, which is associated with each activity. Since 
an activity wifl in general require to access output con- 
tainers of other activities, each activity is associated in 
addition with an Input container too. At run time, the 
actual values for the formal parameters balding the 
4$ input container of an activity represent the actual con- 
text of an instance of the activity. Each data container is 
defined by a data structure. A data structure is an 
ordered list of variables, called members, that have a 
name and a data type. Data connectors represent the 
so transfer of data from output containers to input contain- 
ers. When a data connector joins an output container 
with an input container, and the data structures of the 
two containers match exactly, the RowMark workflow 
manager maps the data automatically. 
ss Connectors link activities in a process model. 
Using connectors, one defines the sequence of activi- 
ties and the transmission of data between activities. 
Since activities might not be Executed arbitrarily they 
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mentad through programs. The programs are registered 
via the Program Definition facility. Blocks contain the 
same constructs as processes, such as activities, con- 
trol connectors etc They are however not named and 
have their own exit condition. If the exit condition is not $ 
met, the block Is started again. The block thus imple- 
ments a Do Until construct Process activities are Imple- 
mented as processes. These subprocesses are defined 
separately as regular, named processes with an its 
usual properties. Process activities offer great flexibility 10 
for process definition. It not only allows to construct a 
process through permanent refinement of activities into 
program and process activities (top-down), but also to 
build a process out of a set of existing processes (bot- 
tom-up). In particular, process activities help to organize is 
the modeling work if several process modeler are work- 
ing together. It allows the team members to work inde- 
pendently on different activities. Program and process 
activities can be associated with a time limit. The time 
limit specifies how long the activity may take. If the time 20 
is exceeded, a designated person is notified. If this per- 
son does not react within another time limit, the process 
administrator is notified, h not only helps to recognize 
critical situation but also to detect process deficiencies 
as all notifications are recorded in an audit traiL # 

AH data structures used as templates for the con- 
tainers of activities and processes are defined via the 
Data Structure Definition Facility- Data Structures are 
names and are defined in terms of elementary data 
types, such as float integer, or string and references to so 
existing data structures. Managing data structures as 
separate entities has the advantage that all interfaces of 
activities and their incrementations are managed con- 
sistently in one place (similar to header files in program- 
ming languages). 95 

All programs which implement program activities 
are defined via the Program Registration Facility. Regis- 
t^ed for each program is the name of the program. Its 
location, and the invocation string. The invocation string 
consists of the program name and the command string 40 
passed to the program. 

Before process instances can be created, the proc- 
ess model must be translated to ensure the correctness 
and completeness of the process model. The translated 
version of the rrod^ isusedasatemplatewhegaprcc- 45 
ess instance is created This allows to make changes to 
the process model without affecting executing process 
instances. A process instance is started either via the 
graphical interface of via the callable process applica- 
tion programming interface. When a process is started, so 
the start activities are located, the proper people are 
determined, and the activities are posted onto the work 
list of the selected people. If a user selects the activity, 
the activity is executed and removed from the work list 
of any other user to whom the activity has been posted, ss 
After an activity has executed, its exit condition is evalu- 
ated If not met the activity is rescheduled for execution, 
otherwise all outgoing control connecters and the asso- 



ciated transition conditions are evaluated. A control con- 
nector is selected, if the concOtion evaluates to TRUE. 
The target activities of the selected control connectors 
are then evaluated. If their start conditions are true, they 
are posted to the work list of selected people. A process 
is considered terminated, if ad end activities have com- 
pleted. To make sure that all end activities finish, a 
death path analysis Is performed. It removes ail edges 
in the process graph which can never be reached due to 
faiGng transition conditions. All information about the 
current state of a process is stored in the database 
maintained by the server. This allows for forward recov- 
ery in the case of crashes. 

42 Concepts 

To achieve an Integration of events within WFMS 
which is as seamless as posstol e the basic approach of 
the current invention is to let events appear as a certain 
type of activity in terms of a WFMS. More precisely this 
patent application teaches how events can. be treated 
and implemented as a subclass of the class of activities 
inheriting (in the sense of object orientation) the com- 
mon properties of activities. 

RcwMark activities are either program activities or 
process activities. Program activities are implemented 
via a program which is invoked when the activity is exe- 
cuted; process activities are implemented via a sub- 
process, which is started when the activity is executed. 
The sequence of execution of the various activities of a 
process model are described vialhe control connectors. 
Activities which are only the target of control connectors 
are called end activities, activities which are only the 
source of control connectors, are called start activities. 
Which control connector is being followed is defined via 
predicates. Each activity is associated with an input 
container and an output container. The input container 
contains the data required by the implementation of the 
activity to perform the correct processing; the output 
container is filled by the activity with information to con- 
trol the process and data to be used by subsequent 
activities. Data connectors are used to describe what 
data from which output container should be used for the 
data in the input container of activities su&sequent 
according to the process graph. Activities are associ- 
ated with a notification mechanism, which allows to 
specify that an action, such as sending a notification 
message to a designated user, is performed, rf the activ- 
ity has not been worked on tor a defined period of time. 

The concept of events is the mechanism which 
allows the process modeler to specify thai the process 
should wart at this point until the specified event hap- 
pens. This event could be that a certain date occurs, or 
that a letter should be received from a customer. The 
occurrence of the event may be signalled from an activ- 
ity within another process or from any other program, 
such as an agent In Lotus Notes. In general an event Is 
an incident occurring independent from an activity 
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informing an activity asynchroneously on some type of 
change. This change might be internal or external to the 
WFMS. The relationship between the activity and the 
event may be such that the activity requires that the 
event is signaled to it otherwise the activity wOl not con- 
tinue beyond a certain point H is also possible that an 
event signaled to an activity wilt be perceived by mat 
activity and depending on that perception might modify 
the activity's ongoing processing. An event might result 
from anywhere within a computer system or even within 
networks of computer systems. Also the source of an 
event might be a hardware device, some software con- 
struct, a human interacting with a running computer 
system and so forth. 

The patent application shows how events can be 
modelled wrlhin a WFMS as a special Wnd of activity, 
the event activity. It specializes in the sense of object 
orient technology the general activity and inherits all 
properties of the general activity. Therefore, an event 
(activity) may be associated with an input and output 
container and may be the source and the target of con- 
trol connectors as well the source and target of data 
connectors; i.e. all constructs and techniques available 
to general activities are available to event activities 
according to the current teaching too. Events may have 
a start condition and may be associated with a notifica- 
tion. An event activity is associated with an event similar 
to process activities which are associated with pro- 
grams. 

Thus an "event" describes a conceptual and 
semantical entity, while the "event activity" is the model 
ol that event modelled with the features of a WFMS. The 
programs associated with the event are caled event 
g eneratois and represent the means and constructs for 
creating or handling a particular event 

Figure 1 reflects multiple aspects of the embedding 
of events as a new type of activity within a WFMS 
according the teaching of the current invention. The new 
type of activity, the event activity 100. is reafized as a 
sub-class of the class of activities 1 01 . Via relationship 
and inheritance mechanisms the ftiH spectrum of fea- 
tures and capabilities available to activities is made 
available to event activities tea Thus event activities 
may exploit the available notification features 102. the 
full spectrum of data structure features 103 or the vari- 
ous connector features like control connectors 1 04 and 
data connectors 105. Also shown by Figure 1 is the rela- 
tionship of the model of an event 106 with one or more 
event activities 100 and the relationship of a program 
107, an event generator implementing or handling an 
event with one or mora event activities 1 06. 

The control connectors originating from an event 
activity are treated as usual, Le. their truth value of pred- 
icates potentially associated with those control connec- 
tors contribute to starting conditions of activities. Also, 
there may be more than one control connector emanat- 
ing from a particular event activity. The usual navigation 
semantics will evaluate the transition conditions of the 



associated control connectors immediately; thus, 
events will not be physically consumed (in the sense 
that an event can be dedicated to a particular control 
connector leaving the event activity node) but are avail- 

5 able for all originating branches. If exclusive validity of 
an event for a particular branch is required it must be 
expressed via suitable transition conditions. 

An event activity can also be a target of a control 
connector. This means that an instance of the corre- 

10 sporting event is created (but not signalled) if the tran- 
sition condition of the control connector pointing to the 
event activity is fulfilled. Using control connectors point- 
ing to event activities can bo used to explicitly activate 
events within particular process instance contexts. If an 

is event is activated the activity waiting for that event has 
registered for that event and an other activities being 
according to the RowMark process model the target of 
a control connector originating at the event activity are 
then potential consumers of that event 

20 Figure 2 illustrates how two different cases for 
embedding events as event activities within a process 
model can be differentiated, exactly as is the case with 
regular activities. On the left side (1), the activity A 201 
must have terminated successfully and the transition 

25 condition 202 between A and the event activity E 203 
must have been evaluated to true* before the event 
node E is sensitive for recognition. Thus, if an instance 
of E is signalled, this is not recognized before the transi- 
tion condition between A and E is met Once E is sensi- 

$0 tive for recognition (La activated) the activity B 204 has 
registered for the appropriate instance of E automati- 
cally through the modelled process graph. Event activi- 
ties for this first type may be used for instance if the 
cause of an event is located at feast partially within a 

sb process model itself. 

On the right side (2), the transition condition 210 
between the event activity E211 and the activity B 212 
win be evaluated as soon as the event E is recognized 
even if the activity A 21 3 has not been terminated. Con- 

40 sequently. E is activated when the process model is 
instantiated, i.e. B has registered for E right away. 

When activating an event activity its associated 
input container is materialized- The usual rules for data 
connectors do apply. The output container of an event 

45 activity is created by the event generator associated 
with the subject event (see below). 

4.3 Components of Event Management Services 

so The navigator is the piece of the workflow manage- 
ment system that performs the navigation through the 
process graph. For bandfing events this navigator is 
extended by an Event Management System encom- 
passing event management services which are inter- 

66 operating with the navigator. These event management 
services are logically different components which may 
or may not coincide with physical means implementing 
those fcmctions. Figure 3 reflects the major components 
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of the event management services. The event monitor 
301 i$ responsible for keeping track of awaited and 
posted events. The event generators 302 are pro- 
grams that signal the occurrence of an event to the 
event monitor. The event manager 303 keeps tie infor- 
mation about events. 

When the navigator 304 detects that an event is 
expected by particular activities of a process instance 
this Is indicated to the event monitor, rf the event monitor 
finds a matching entry in its posted event table 80S ft 
indicates so immediately to the navigator and passes 
the associated data with its response. Otherwise, the 
©vent monitor reflects thft awaited event by an appropri- 
ate entry in the awaited event table 306. 

An event generator signals the occurrence of an 
event to the event monitor. The event monitor verifies 
the correctness of the event by consulting the event 
manager, tf the event monitor detects a corresponding 
entry in the "awaited event table" this is indicated to the 
navigator. Otherwise, the event is inserted into the 
"posted event table". 

The tables "awaited event table" and "posted event 
table" are first of all logical objects. Physically they actu- 
ally may be implemented as different or as common 
tables, 

44 Tracking of Events 

It can be perceived that events and their event indi- 
cations within the posted and awaited event table are 
managed in tabular formats as depicted in the Figure 4. 
ProcID refers to the identifier of the process instance in 
which the event is waited tor. The EventlD identifies a 
particular event in this process instance (as node in the 
process model). The EventName refers to the category 
of the event and the InputContainer oolumn contains the 
actual values of the fields in the associated input con- 
tainer of the event. 

It has to be noted that the EventlD is needed 
because events having an incoming control connectors 
are only "activated* if the transition conditions of the 
incoming control connectors are met and the start con- 
dition is true. An event which is not activated is not 
reflected in the "awaited event table". Events with no 
incoming control connector are activated at process 
instantiation time. 

The posted events table is used to store generated 
events which are currently not waited for as no potential 
consumer has registered tor it Such an event is kept in 
this table until somebody registers tor it (potentially, an 
event may be kept "forever") or if it is removed via gar- 
bage collection. The ProcID column in this table repre- 
sents an optional value tor tupels of this table and can 
be used for specifying particular process instances 
which might consume the event instance. 



4.5 Cancelling Events 

An awaited event can be cancelled in two ways : (1) 
as the result of a notification action, such as FORCE 

s TERMINATE or (2) through an explicit request from the 
user via functions supplied by the event monitor. When 
an awaited event ts cancelled, it is removed from the 
waited event table and the event monitor signals the 
completion of the event to the navigator. Any outgoing 

to control connector is treated as if the event had hap- 
pened normally. 

4*6 Event Identification 

1$ The association of an incoming event, such as 
receiving a letter, with the wailed for event is perfonmed 
by comparing the identification fields provided by the 
event generator with the Fields defined in the input con- 
tainer plus the fields defined in the input container by 

so default which is the process instance identification and 
the event identification. No problem arises if the event 
generator itself provides the process instance identifica- 
tion and the event identification. If the process instance 
identifier is not supplied, the fields in the input container 

26 are compared wrfo the appropriate fields delivered by 
the event generator (signature matching). 

4.7 Event Generator 

$o The event generator signals that an event has hap- 
pened by calling the event monitor via the event monitor 
interface. The event generator can determine when the 
event should be signalled. This can be done by periodi- 
cally querying the event monitor to determine K a new 

3s entry for the event generator has been entered in the 
awaited event table. An event generator may also regis- 
ter itself with the event monitor and request that each 
new registration of an awaited event is signalled to the 
event generator. 

40 The supplied datetime event generator for example has 
a data structure with a date field and a time field. These 
fields can either be filled by a data connector leading to 
that event or values sat as defaults by the process mod- 
eler. The timeAlate event generator has registered with 

4S the event monitor that it should be called when a new 
event is registered. 

4.8 Event Monitor Programming Interface 

so The event monitor provides an application program- 
ming interface to allow applications to request event 
monitor functions. The set of functions include requests, 
such as querying the posted event table, removing 
entries from the posted event table, querying the 

55 awaited event table, removing entries from the awaited 
event table, and inserting entries into the posted event 
table. 
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4.9 Event Registration 

An event activity is always associated with an 
event. The event has a number of properties: the name 
oi the program implementing the event generator, the s 
name of the event, and an indicator whether the event 
generator should be started as part of starting the Row- 
Mark server. An important property is the operation 
mode of the event generator, which defines whether the 
event generator should be called every time a new event 10 
is added to the awaited events table or not If specified, 
this allows the event generator to keep internal tables 
for efficient processing and does not require periodically 
reading the awaited event table. 

1$ 

4.10 Event Notification 

Events also inherit (in the sense of object oriented 
technology) the notion of notification from the activity. 
Notification allows to define actions which are taken so 
whenever the defined time for completion is exceeded. 
Extensions to the notification mechanism allow to spec- 
ify other actions than just sending a notification mes- 
sage to a designated person. These extensions include 
actions like terminating the activity. 

4.11 Process Model Additions 

The support of events requires minor additions to 
the FlowMark Definition Language (FDL). so 
Events are registered (in the sense of the FDL} via the 
EVENT section, it is similar to the PROGRAM section 
which supports the registration of programs. Figure 5 
shows the FDL registration of the event "Walt for Cus- 
tomer Response*. The associated generator program as 
is "MailCheckProgram". The program is started as a 
result of starting the FlowMark server, specified due to 
AUTOSTART, and is notified whenever an event is 
entered into the awaited event table, specified due to 
NOTIFY. <o 

Event activities of a process model are defined via 
the EVE NT_ACTIVlTY section. This mechanism is 
almost identical to the PROGRAM JUJTIViTY keyword. 
The event type is specified via the EVENTTYPE key- 
word followed by a string containing the event type. A 45 
particular event type may be specified only once within 
a process model. Figure 6 shows how an event is 
defined. The data structure "Event Identification* 
defines the structure of the input container associated 
with the event It contains all relevant information to $0 
identify the event This information is used by the event 
monitor to compare it with the information supplied by 
the event generator. The data structure "Response 
Information* defines the structure of the output con- 
tainer associated with the event The data is supplied by ss 
the event generator. 

Notification of events is enhanced to provide the 
capability to force terminate the event that means that 



the event is considered complete even if no event has 
been signalled during the specified time. Figure 7 
shows how it could be specified that it should only be 
waited 14 days tor the customer letter to arrive. 

4.12 Advantages 

The proposed method of treating events as activi- 
ties has, besides the effect of offering a seamless exten- 
sion and transition of workflow activities, a number of 
advantages over other possible approaches that treat 
events differently. 

1 Events follow the same metaphor as activities. 

1.1 Control Connectors activate an event. 
The predicates on the incoming control con- 
nectors as well as the outgoing control connec- 
tors allow to specify which event should be 
waited for and which activity should be exe- 
cuted as the result of the happening of an 
event. Events wiftout an incoming control con- 
nector are immediately activated as are start 
activities, 

1 .2 Data Connectors allow to fill the input con- 
tainer wfti the event relevant data No new 
mechanism is required to identify the instance 
of the event for which it should be waited for. 

1 .3 Input Containers identify to activities what 
the context is in which they are called. The 
same is true for event activities as the contents 
of the input container identifies the particular 
characteristics of the event which is waited for. 

1.4 Output Containers contains the process 
relevant information generated by an activity. 
For event activities, the event signaller provides 
this information, for example, the identification 
of the letter which has been received, which is 
process relevant information, 

1.5 Notification allows to specify what should 
happen if an activity has not been completed 
within a defined time Emit The same behavior 
is true tor event activities, where this mecha- 
nism is used in the same way. 

1.6 Events can be handled within Spheres of 
Joint Compensation the same way as activi- 
ties. 

2 Events can be graphically managed the same 
way as are activities. 

3 Events can be described in the FlowMark Defini- 
tion Unguage with similar constructs as program 
activities. 

4 Treating events as activities allows to re-use the 
code used for processing process models, such as 
navigating the graph. Re-use of this code Provides 
a number of advantages, such as 
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4.1 Lass errors 

4.2 Easier testing 

5 Events can be monitored the same way as other 
activities via the process tnstanceHnonitor 

Ail in all these advantages help to compactify the 
overall system, contribute to minimize the implementa- 
tion effort and thus Increase the responsiveness of the 
WFMS, 

4.13 Example 

A simple process model in Figure 8 Mustrates the 
usage of events. In a claims processing application of 
this example additional info is required from a customer 
601 . The process waits until information is received 802. 
If the customer responded via fax, th&fex is processed 
with a certain piece of software 803. otherwise another 
piece of software is used 804. 

Figure 9 shows the definitions of the most important 
data structures being of importance within the example 
of Figure & Finally Figure 10 is a visualization of the 
event modeled as an event activity "Walt for 
Response" in lines 5 to 9 within the process model of 
the example of Figure 8. Figure 10 further demonstrates 
in lines 14 to 21 usage of control connectors and in line 
21 to 31 usage of data connectors for the event activity. 

5 Acronyms 

DB Database 

FDL FlowMarfc Definition Language 
WFMS Workflow Management System 

Claims 

1. A computer system encompassing one or more 
computers storing an implementation of a process- 
model for a woritflcw-process-environmenl said 
process-model managed and executed by said 
computer system, said computer system being 
characterized by 

at least one event-activity encompassed by 
said process-model said event-activity being 
implemented as an activity of said workflow- 
process-environment 
and 

said event-activity managing an event occur- 
ring internal or external to the worWlow-proc- 
ess-environment. 

2, A computer system according to claim 1 
wherein said event-activity being implemented by 
inheriting features and capabilities of the class of 
activities or of a sub-class thereof according to the 



principles of object-orientation. 

3. A computer system according to any of above 
claims 

s wheresi said event-activity is associated with 

an event, and 

wherein said event-activity may have associ- 
ated with it an input-container and/or an output-con- 
tainer, and 

10 wherein said event-activity may be the 

source andtor target of one or more control-connec- 
tors, and 

wherein said event-activity may be the 
source and/or target of one or more datas&nnec- 
15 tors, and 

wherein said event-activity may be associ- 
ated with a notification-mechanism allowing to 
freely define at least one action to be performed by 
the wcdtf low-process-environment if said everrt- 
20 activity is not completed within a freely defined time 
period. 

4. A computer system according to claim 3 

wherein said event is implemented by an 
25 event-generator. 

& A computer system according to claim 4 

wherein said event-generator is imple- 
mented as a program. 

so 

6, A computer system according to anyone of daim 3 

tos 

wherein said action automatically terminate 
said event-activity. 

9$ 

7. A computer system according to any of above 
claims 

wherein said process-model encompassing 
at least one ciitgojng-contml-oonnector said event- 

40 activity being the source and a target-activity being 
the target of said outgoing-control-connector, and 

whereta said outgoing-controKionnector 
optionally may be associated with a logical predi- 
cate as ciitgoing-transHfon^orKfition, and 

45 wherein said wc^lolow-proc^ss-envlrcfimeni 

activates said target-activity if said event is signal ed 
to said waiting event-activity and finally said 
eventactivHy terminated and if said outgoing-transi- 
fion-condition evaluates to true. 

so 

8, A computer system according to any of above 
claims 

wherein said workflow-process-environm ent 
is activating said event-activity automatically when 
55 instantiating said process-model H said event-activ- 
ity is no target of a control-connector. 

9. A computer system accorcfng to daim 1 to 7 
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wherein said process-model encompassing 
at least one incomng-controi-connectcr said event- 
activity being the target and a source-activity being 
the source of said incoming-control-connector, and 

wherein said irKsminp/Cc^i^I-connsctor b 
optionally may ba associated with a logical predi- 
cate as incomno/transltx>n<ono^tion f and 

wherein said workftow-process-envirortment 
activates said event-activity if said source-activity 
terminated and said incorring^transittorv^ i$ 
evaluates to true* 

10. A compute* cysfam according to daim 7 to 9 

wherein said workflow-process-environment 
registers said event-activity as awaiting consumer is 
of said event once said everrt-activrty is activated by 
said workflow-process-environment, and 

wherein further said worWiw-prccess-envi- 
ronment registers said event as posted-event once 
the occurrence of said event is signaled by said 20 
event-generator. 

11. A corr^er system according to claim 7 to 10 

wherein said target-activity is activated by 
said workflow^rocess-erwironment if as a first con- zs 
dition said event-activity terminated and if as a sec- 
ond condition said c»u^drig-transition-conc5iion 
evaluates to true independent at which point in time 
and in which sequence said first and said second 
condition are fulfilled. 30 

12. A computer system according to claim 10 encom- 
passing a worW tow-navigator performing navigation 
of operation trough the process-graph of said proc- 
ess-model and said computer system befrig further 35 
characterized by 

an everrtHT)anagemant-syst$m extending and 
inter-operating with said workflow-navigator, 
and 40 

said event-management-system encompasses 
the component of an event-monitor administer- 
ing awaited events in at least one awaited- 
event-table and further administering signaled 45 
events in at least one pcsted-evenMable, and 
wherein said event-generator is signal- 
ing the occurrence of said event to said event- 
monitor. 

so 

13. A computer system according to claim 12 

wherein said evert-management-system 
encompasses the component of an event-manager 
maintaining information on said event allowing to 
verify correctness of said event if said event is being ss 
signaled. 

14. A computer system according to claim 13 



wharain said worWIow-navigator sends, if it 
detects that said event-activity is awaiting for said 
event, an awaited-evenfrnotiftcation to said event- 
monitor and if then said event-monitor detects a 
matching posted-event-indication in said posted- 
event-tabte said event-monitor indicates said event 
together with event-data to said worWIow-navf gator 
or if otherwise no matching posted-event-notifica- 
tion is detected said event-monitor stores an 
awarted-event-lndication in said awaited-event- 
table, and 

wherein said event-generator indicates the 
occurrence of said event by a posted- everrt-lncfica- 
tion to said event-monitor which verifies said 
posted-event-tnolcation by consulting said event- 
manager and then stores said posted-event-indtca- 
tion in said pested-event-tatfe and if then said 
everrt-rnonitor detects a matching awaffing-evertt- 
indicatfon in said awaiting-event-table it indicates 
this together with event-data to said workf tow-navi- 
gator. 

15. A computer system according to claim 14 

wherein said event-generator is informed, if 
said awaiteo^event-cnrJcation is stored in said 
awaited-event-table, on this awaHed-event-indica- 
tioa 
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1 EVENT 'Wait for Customer Response' 

2 EVENT_GENERATOR «HailChecJtFrogram« 

3 AUTOSTART 

4 NOTIFY 



FIG. 5 



1 EVENT ACTIVITY 'Wait for Response' 

2 ('Event Identification', 'Response Information') 

3 EVENT 'Wait for Customer Response 1 

4 END 'Wait for Response ' 



FIG. 6 



1 EVENT_ACTIVITY 'Wait for Response' 

2 ('Event Identification' f 

3 'Response Information*) 

4 EVENT . 'Wait for Customer Response' 

5 NOTIFICATION 

6 AFTER 14 DAYS FORCE FINISH 

7 END 'Wait for Response' 



FIG. 7 



1 STRUCTURE ' Event Identification 1 

2 'caee number' s STRING j 

3 'customer name* : STRING ; 

4 END 'Case information* 

5 STRUCTURE 'Response Information' 
€ 'response ID' * STRINO ; 

1 'type' s STRING : 

8 END 'Letter Information 1 

9 STRUCTURE. 'Case Information* 

10 'case number' : STRING ; 

11 'customer name' s STRING ; 

12 'response id' ? STRING j . 



FIG. 9 



18 



EP 0 854 431 A2 




Proosss letter 
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1 PROGRAM ^ACTIVITY 'Request Customer Info' 

2 ('Default Data Structure", 'Case Information') 

3 PROGRAM 'RequestCustonerlnfo* 

4 END 'Re<jucot Customer Info* 

5 EVEMT_ACTrVITY 'Wait for Response' 

6 ('Event Identification', 

7 'Rcoponae Information' ) 

8 EVENT T¥PE 'Wait for Customer Response 1 

9 END *Wait for Response 4 

10 PR0GRAM_ACTIVITY 'Proceaa Fax 1 

IX ( * Case Information • , ♦ Def aultcataStructure ' ) 

12 PROGRAM 'Proceaa Fax* 

13 END 'Proceaa Fax 1 

Id CONTROL FROM 'Request Customer Info* 

15 TO 'Wait for Response * 

16 CONTROL FROlil 'Wait for Response' 

17 TO 'Process Fax 4 

18 WHEN 'type = "FAX*" 

19 CONTROL FROM 'Wait for Response' 

20 TO 'Process Letter' 

21 WHEN 'type = "LETTER" ' 

22 DATA FROM 'Request Customer Info* 

23 TO 'Wait for Response' 

24 DATA FROM 'Wait for Response* 

25 TO 'Proceaa Fax' 

26 DATA FROM 'Request Customer Info' 

27 TO 'Process Fax' 

28 DATA From 'Wait for Response' 

29 TO 1 process Letter 1 

30 DATA FROM 'Request Cuetomer Info' 

31 . TO 'Process Letter* 
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